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Transformer Class: SIToVtAddProductTransformer 

Description: This class directs the data transformation from the Siebel 
Add Product system event to the Vitria Add Product business event The 
Siebel Controller Class will invoke this class when the Add Product system 
event is received from the Siebel Servlet Source. This class will perform 
two main functions: 

1. Invoke the SIIDLBuilder class to transform data from the Siebel 
Integration Object format to IDL format(Please refer to the IDL Detail 
Design document for IDL format.) 

2. Return information in IDL format to the Siebel Controller Class to be 
published to a channel. 



Class Variables: 
Instance Variables: 
Method(s): 



Method Details 
Exception(s): 



None 
None 

1. performWork 

Description: This Method will transform the 
Vitria Product business component fields 
retrieved for the Add Product system events 
to IDL fields to be published by Vitria. 



Parameter(s): 



1. Type: AcknowledgementException 
Description: This contains the account id, 
business event, external application, success 
indicator, element, element id, error message, 
bpid and eventXML. 

1. Name: pEventBody 
Type: EventBody 

Description: The eventBody parameter holds 
the event specifications such as the name of 
the event, and the parameters of the event. 

2. Name: pSti 

Type: SimpleTranslatorlnterface 
Description: The SimpleTranslatorlnterface 
contains the log level and is used this to write 
log messages to the appropriate log file. 
Event Body Parameter (s): 1. Name: SiebelMessage 

Type: SiebelMessage Event 
Description: The SiebelMessage parameter 
contains two sub parameters i.e., a sequence 
of Product Instance struct and attributes of 
the SiebelMessage event. 
1. Name: eventBody 
Type: EventBody 

FIG. 2A 



Return Value(s): 
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Controller Class: PIController 

Description: The Portal Controller (PIController) class will be developed 
to direct the business events from Vitria to the correct transformer class. 
Each business event has a different process that needs to be performed 
to create the appropriate system events. There are two functions that this 
class performs: 

1. Directs events to the appropriate transformer class. Each business 
event will have a separate transformer class that will process the 
business event into the appropriate system event. 

2. The system event (i.e. vtOpCode event) is received back from the 
transformer class. This class will then return the event to the 
connection model to be sent to the next flow (Portal Target Flow). 

Class Variables: None 

Instance Variables: None 

Method(s): 1. getTargetEventlnterfaceList 

Description: This method is a public static 
method which will set the default input 
Event Interfaces for the Data Transformation 
flow when the PIController class is selected. 

2. getSourceEventlnterfaceList 
Description: This method is a public static 
method which will set the default output 
Event Interfaces for the Data Transformation 
flow when the PIController class is selected. 

3. targetTranslation 

Description: This method will decide what 
transformer class corresponds to the input 
event. The transformer name and event are 
then passed to the callTranslation method. 
The targetTranslation method will be a public 
method. 



FIG. 2B-1 
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Method Details 

LgetTargetEventlnterfaceList 

Exception(s): 
Parameters): 



4. callTranslation 

Description: This method will direct the 
event to the specified event transformer 
class and call the applicable transformer 
method. The callTranslation method is a 
private method within this class. 

5. sourceTranslation 

Description: This method overrides the 
sourceTranslation method in the super 
class. We must include this method in the 
PIController class because it is declared as 
abstract in the BaseController. However, 
we will not perform any actual data 
manipulation at this time, so we will 
simply return null. 

6. getEventXML 

Description: This method will retrieve the 
source event, and translate it into a xml 
string. 



Return Value(s): 



None 

1. Name: strMethodName 
Type: String 

Description: The name of the method which 
was selected by the user within the 
Processing Tab for a Simple Transformer 
in the Vitna BW console. 

2. Name: translateParams 
Type: String[] . . 
Description: This parameter is not used in 
this method, but is required by Vitria BW 
to implement this method. 

7. Name: resolver 
Type: MetaResolver 

Description: The MetaResolver handles the 
switch between editable and registered 
versions of the event list. 
1. Name: eventBody 
Type: EventBody 



FIG. 2B-2 
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2. getSourceEventlnterfaceList 
Exception(s): I 
Parameter(s): 



None 

1. Name: strMethodName 



Type: String 

Description: The name of the method which 
was selected by the user within the 
Processing Tab for a Simple Transformer 
in the Vitria BW console. 

2. Name: TranstateParams 
Type: Stringf] 

Description: This parameter is not used in 
this method, but is required by Vitria BW 
to implement this method. 

3. Name: resolver 
Type: MetaResolver 

Description: The MetaResolver handles the 
switch between editable and registered 
versions of the event list. 



Type: EventBody 

Description: The eventBody parameter 
holds the event specifications such as the 
name of the event, and the parameters 
of the event. 
2. Name: sti 

Type: SimpleTranslatorlnterface 
Description: Use this to write log messages 
to the appropriate log file and retrieve 
the log level. 



Return Vaiue(s): 



None 



3. targetTranslation 

Exceptions): 

Parameter(s): 



None 

1. Name: eventBody 



Return Vafue(s): 



Name: SystemEvent 
Type: EventBody 



FIG. 2C-1 



4. callTranslation 

Exceptions): 

Parameters(s): 



Return Value(s): 

5. sourceTranslation 

Exception(s): 

Parameters(s): 



Return Value(s): 

6. getEventXML 

Exception(s): 

Parameter(s): 



Return Value(s): 
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None 

1. Name: eventBody 
Type: EventBody 

Description: The eventBody parameter 
holds the event specifications such as the 
name of the event, and the parameters 
of the event. 

2. Name: sti 

Type: Simple Translatorlnterface 
Description: SimpleTranslator to retrieve 
log level and write log messages. 
Name: SystemEvent 
Type: EventBody 

None 

1. Name: eventBody 
Type: EventBody 

Description: The eventBody parameter 
holds the event specifications such as 
the name of the event, and the parameters 
of the event. 

2. Name: sti 

Type: SimpleTranslatorlnterface 
Description: SimpleTranslator to retrieve 
logger instance and log level. 
None 
FIG. 2C-2 

None 

1. Name: sti 

Type: SimpleTranslatorlnterface 
Description: SimpleTranslator to retrieve 
logger instance and log level. 
Name: xmlEvent 
Type: String 

FIG. 2D 
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Acknowledgement Class: SlAcknowledgementTransformer 

Description: This class directs and transforms the Siebel Response 
Message that ^zults from the completion of a Service Status 
Notification or Update Product Status event to an Acknowledgement 
business event. 



The Siebel Controller Class will invoke this class when the Siebel 
Response Message is received from the Siebel Target Driver. This class 
will perform two main functions: 

1. Transform information from a Siebel Business component 
format to an IDL format. (Please refer to the IDL Detail Design 
document for IDL format.) 

2. Return information in an IDL format to the Siebel Controller Class to 
be passed to the Acknowledgement Channel. 



Class Variables: 
Instance Variables: 
Method(s): 



Method Details 
Exception: 



None 
None 

1. performWork 

Description: This method will transform 
the incoming Siebel Response Message 
into IDL fields to be published in Vitria. 

1. Type: AcknowledgementException 
Description: This contains the account 
id, business event, external application, 
success indicator, element, element id, 
bpid, and eventXML 



FIG. 2E-1 
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Parameter(s): 1 . Name: pEventBody 

Type: EventBody 

Description: The eventBody parameter 
holds the event specifications such as 
the name of the event and the 
parameters of the event. 
2. Name: pSti 

Type: SimpleTranslatorlnterface 
Description: Use this to write log 
message to the appropriate log file. 

Incoming Siebel 

ResultsEvent Body Parameters: 1. Name: status 

Type: String 

Description: The status field is either 
Success or Error, indicating whether 
the event was processed correctly. 
2. Name: error 
Type: String 

Description: The error field contains 
any error message that occurred while 
processing the Siebel operation. 
Return Values: 1. Name: eventbody 

Type: EventBody[] 



FIG. 2E-2 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


1 


Add Product 


Siebel 


The "Add Product" event will send (service element) 
inlormation to Vitria. This event is triggered in the CRM 
application when the "Submit order button is pressed 
for an order. A Siebe! workflow sends the necessary 
account information to Vitria M format via an HIJP 
protocol. 


2a.1 


CreateOrder.Request 


OMS 


Vitria sends a ProvisionRequest to OMS through the 
OMS target connection model which then translates it 
into a CreateOrder. Request event. 


2a.2 


CreateOrder.Response 


OMS 


Upon provisioning, the OMS source connection model 
receives a CreateOrder. Response event from OMS 
which is then translated into a ProvisionResponse. 


23.3 


ServiceStatusNotikation 


OMS 


OMS will also send to Vitria a ServiceStatusNotification 
event indicating the status of the account related to the 
ProvisionRequest. 


3b.l 


Find Customer 


Portal 


As a result of the Add Product system events, Vitria 
receives an account number. Portal uses the account 
number and the opcode 

PCM_OP_CUSTJIND to determine the poid of the 
account Mis getting new products added. 


3b.2 


Find Sen/ice 


Portal 


If CRM does not send Portal service information for this 
business event, Intranet assumes the deal was intended 
to be attached at the account level, not at the service 
level. If CRM sends portal service information, it will 
be necessary to retrieve the service poid in order to 
attach the product to that service. Portal uses the 
Service Type, Service Login, Account ID and the opcode 
PCM_OP JEARCH to determine the poid of the service. 
*Note: If CRM fails to send service information for a 
defined service-level deal, Portal will sendbackan 
error to Vitria. 


3b.3 


Find Deal 


Portal 


This system event uses the deal name to call the 
opcode PCM OP OUST POL GET DEALS. This 
will retrieve all tie deals that are available. Internally, 
the wrapper opcode will iterate through each of Die 
deals in order to match it to the deal's name. 



FIG. 5B-1 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


3b.4 


Add Deal 


Portal 


The final opcode that may be called is PCMJ3P_ 
BILL_PURCHA$E_DEAL. This opcode will Fake h 
account poid, deal poid and optionally the service 
poid, This information will be used to add new deals 
to the accountlservice specified. 


OU.J 


Arknnwlprfnement 


Portal 


A response will be sent back from the Portal to Vitria 
indicating if the product has been successfully added 
or not. Vitrla-IOM will transform this Acknowledgement 
event into an ServiceStatusNotification event to send 
to Siebel. 


4c.1a 


Insert Account Component 


Arbor 


The insert account component event will be called 
when a new component is added at the account level. 
The component will be associated at the account 
level, and attached to the dummy package. 


4c.1b 


Insert Service Component 


Arbor 


The insert service component will be called when a 
new component is added to an account at the service 
level. The component will be associated to the 
service instance. 


4c.2a 


Activate Account 
Component 


Arbor 


Once the account component has been inserted into 
the database, it must be activated individually in the 
activate APIs before billing can begin. Each component 
must be activated individually. 


4c.2b 


Activate Service 
Component 


Arbor 


Once the service component has been inserted into 
the database, it must be activated individually in the 
activate APIs before billing can begin. Each component 
must be activated individually. 


4c.3 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating that the component has been successfully 
entered or not. An acknowledgement event will be 
sent to the acknowledgement channel. 



FIG. 5B-2 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


? 


Add Service 


Siebel 


The "Add Service" event will send service instance 
information to Viiria. This event will be triggered in the 
CRM application when the "Submit' order button is 
pressed for an order. A Siebel workflow sends the 
necessary account information to Vitria XML format 
via an HTTP Protocol. 


2a. 7 


Insert Service 
Instance 


Arbor 


The service instance event will create a new instance 
of a service instance object, and will associate the 
service instance id and a service location to a billing 
account. 


2a.2 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating if the service has been successfully 
entered or not. 


3b.1 


Find Customer 


Portal 


As a part of the Add Service system event, CRM passes 
the Account ID to Vitria. The wrapper opcode uses the 
AccountID and the opcode PCMJJPJUSTJIW 
to determine the account POID. 


3b.2 


Create Service 


Portal 


The Create Service Portal system event will occur only 
after ail of the products associated with that service 
have been provisioned (forl-Hub R3.0, 10 products will 
be provisioned by OMS, all other products provisioning 
status will be defaulted) and the associated account 
has been sent to Portal. 

Once the account POID (account identifier) has been 
received by Portal, the wrapper opcode calls 
PCM_OP_CUST_CREATE_SERVICE to create a service 
instance in the intranet daJabase. 


3b.3 


Acknowledgement 


Portal 


A response will be sent back from the Portal to Vitria 
indicating if the service has been successfully entered 
or not. 


4 


HIA 


IOM 


Vitria IOM will utilize the information within the 
addService event to create a ProvisioningRequest 
event to be sent to the Provisioning system. 



FIG. 5C 
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Se- 
quence 


Svstem Event 


Appli- 
cation 


Description 


1 


Add Account Level 
Adjustment 


Siebel 


//?e Apply Account Level Adjustment event senas 
account adjustment information-credits and debits- 
from Siebel to Wia. This event will be triggered when 
f/?e /lecounf [era Adjustment applet is committed in 
Siebel, The Siebel Workflow sends the account level 
adjustments to Wia in XML format through HITP 
protocol. 


2a 


Find Customer 


Portal 


Portal uses the account number In the opcode 
PCM OP Cf/sr FIND to determine the account Pull). 


2b 


Apply 
Adjustment 


Portal 


The adjustment amount, account POID, and reason 
description are passed into PCM_OP_BILLJCCOUM 
&n hi^wfut tn annlv the adjustment to the account 


2c 


Acknowledgement 


Portal 


A response will be sent back from PortsI to Yitha 
indicating whether the adjustment has been 
successfully applied or not. 


3a 


Apply Acct 
Level Adj 


Arbor 


This event will be used to apply a credit adjustment to 
an accounts overall charges within Arbor. The 
account-level adjustment will be made by creating the 
Adjustment API object and calling the Insert Misc 
function to apply the credit to the appropriate account. 


2b 


Acknowledgement 


Arbor 


A response wilt be sent back from Arbor to Vitria 
indicating whether the adjustment has been 
successfully applied or not. 



FIG. 5D 
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Se- 
quence 


System Event 


AddH- 

"rr" 

cation 


Description 


1 


Cancel Deal 


Siebel 


The "Cancel Product will be triggered to send 
information to Vitria when a deal has been cancelled 
either by clicking Cancelled" button or by changing the 
status field in Siebel. Siebel Workflow sends necessary 
product information to Vitria in XML format through 
HHP protocol. 


2a 


Find Customer 


Portal 


As a result of the Cancel Product system event, Vitria 
receives as account number. Portal uses the account 
number in the opcode PCM OPMJW to 
determine the account POlfT. 


2b 


Read Acct Products 
(Replacing Find Deal) 


Portal 


The wrapper opcode uses the partial poid of the 
account object to call 

PCM OP CUSJ READ ACCT PRODUCTS (replacing 
GET 'DEALS) to determine the'account deals and node 
location. 


Or 




Portal 


Pass the account POID, deal POID, effective 
cancellation date, and (optional) service POID to 
PCM OP BILL CANCEL DEAL to cancel the deal at 
the account or service level. Default date to the correct 
effective date. 


2d 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the deal has been successfully 
cancelled or not. 


33.1 


Cease Account 
Component 


Arbor 


This event will be used to cancel an instance of a 
component that is associated at the account level 
within Arbor. The cease function is used to cancel the 
unique occurrence of the Product Package Account 
Component API object. 


Q4.Z 


UudbV outv If tot 

Component 


Arhnr 


Thfc pi/pnf will hp uwd to cancel an instance of a 
component that is associated at the service instance 
level within Arbor. The cease function is used to cancel 
the unique occurrence of the Product Package Service 
Instance Component API object. 


3b 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitna 
indicating whether the deal has been successfully 
cancelled or not. 


4 


MIA 


I0M 


Vitria IOM will utilize the cancelProduct information 
to create a provisioningReguest event to ensure the 
proper provisioning tasks are completed to disconnect 
the product. 



FIG. 5E 
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Se- 
gue/ice 


System Event 


Appli- 
cation 


Description 


1 


Cancel Service 


Siebel 


The "Cancel Service" event will be triggered to send 
information to Vitria when the "Cancel 1 biMon tor that 
service is clicked in Siebel. A Siebel Workflow sends 
the necessary account information to VMa in Ml 
format via an HUP protocol. 


2a 


CreateOrder.Request 


OMS 


Vitria sends a CreateOrderRequest (Provisioning 
Request) event to OMS with the expectation of a 
CreateOrder.Response (ProvisioningResponse) event 
followed by a ServiceStatusMification event. 


?b 


CreateOrderResoonse 


OMS 


A CreateOrder.Response (ProvisioningResponse) will 
be sent back from OMS to Vitria ■ See step 2b above. 


3a 


Find Customer 


Portal 


Portal uses the account number in the opcode 
PCM OP CUST FIND to determine the account POID. 


3b 


CustReadAcct 
Products 


Portal 


PCMWMSMEADJCCTfRODUCTS uses the 
partial poid of the account object to determine the 
hierarchy of services. 


3c 


Cancel Service 


Portal 


Pass the account POID, service POID, effective date, 
status, and status flags to PCMJPMSTjETJWWS 
to cancel the service. 


3d 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the service has been successfully 
cancelled or not. 


4a 


Cease Service 
instance 


Arbor 


This event will be used to cancel a service instance 
within Arbor by calling the cease function on the unique 
occurrence of the service instance object. 


4b 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the service has been successfully 
cancelled or not. 



FIG. 5F 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 




Create Account 


Siebel 


The "Create Account event will be used to send account 
information from Siebel to Vitria. The Create Account 
event is triggered in Siebel when the "Submit order 
button is pressed for a new customer. A Siebel . 
worKiiow senos ine necessary account iniormauon w 
Vitria in M format via an HtJP protocol. 


2a. / 


Insert Account 


Arbor 


This event will be used to construct the account within 
Arbor by creating the acctAPI object and using the 
insert function to write the account information to the 
appropriate Arbor database. 


2a.2 


Insert Product 
Package 


Arbor 


Add a product package to an existing account. 


2a,3 


Activate Product 
Package 


Arbor 


Activate the product for the account 


2a.4 


Insert Tax 
Exemption 
Info 


Arbor 


lax exemption Information is set for the account by 
populating the lax Exemption API object and calling the 
insert function to write this information to the 
appropriate Arbor database. There are four tax 
exemptions, one each for federal, state, county 
and city. 


2a.5 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the account has been successfully 
created or not. 


2D.1 


Find Parent 
(Find Customer) 


Portal 


If a parent account number is passed across the Vitria 
interface, then the wrapper opcode will Invoke 
PCM OP OUST FIND in order to establish the poid 
value'of tHe parent account. This event will also 
determine whether the parent Is a member of a group. 


a».2 


Commit Customer 


Portal 


Once all of the poids have been retrieved based on the 
information passed from the Vitna interface, the 
www opcode calls PCM OP OUST COMMIT 
CUSTOMER in order to load' altlhe new customer 
information into the intranet database. 


2b. 3 


Move Member 


Portal 


If the account is a non-Master account, then the 
wrapper opcode wiil call PCM OP BILL GROUP 
MOvEJRtMBER to associated child account 

LU a fJQl tin dvOfu/a. 


2b.4 


Set Tax info 


Portal 


When present, tax exemption information is passed 
with the account POID and associated with the 
account with the PCM OP CUST SET TAMFO 
opcode, (lax exemptions are not'n scope for R3.0) 


2b.5 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the account has been 
successfully created omot. 



FIG. 5G 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 




Modify Account 


Siebel 


The "Modify Account event will be used to send 
cnanges to a customers auriDuies irom oieuei w 
Vitria. Me: Currency cannot be changed for any 
account. The Modify Account event is triggered in 
Siebel when a customers account iniormauon is 
modified. A Siebel workflow sends the necessary 
account information to Vitria in ML format via an 
HTTP protocol. 


2a J 


Update Account 


Arbor 


JIws eye/rf iw//it>e used to update contact, billing, 
address, credit card, and other account related 
information for an existing account in Arbor. 


2a.2 


Update Tax 
Exemption info 


Arbor 


This event will be used to update tax exemption 
information in the appropriate Arbor database. There 
are four tax exemptions, one each for federal, state, 
county, and city. 


2a.3 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the account has been successfully 
modified or not. 


2b.1 


Find Customer 


Portal 


This event pulls the Account ID from Vitria. Once this 
information has been received, the opcode 
PCM OP CUSTJiND is called to determine the puiu 
of the account. 


2b.2 


Update Customer 


Portal 


Once the account POID has been retrieved this 
event calls the opcode 

no in nn niioT f/Dfl/ITE P/fOTYlMCD in nrHor tn 

PCM OP Ci/o/ UruHitjjUoiUmtn in oroer w 
make'any applicable updates to the customer 
information into the Intranet database. 


2b. 3 


Set Tax Info 


Portal 


\ftfhnn nnnrinrl fov QVQmnfinn mnrfff/r^f/flfK 3fP fiP^Pf/ 

vWSit IiBGuGU, laX uAUuljJuUU illUUiuijauUlio d/c jjaoozu 

with the account POID and associated with the account 
with the PCM_OP_CUSTJETJAMFO opcode. 
(This is out of scope for ihub R3.0) 


2b.4 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the account has been successfuily 
modified or not. 



FIG. 5H 
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Se- 
quence 


System Event 


Appli- 
c3tion 


Description 


1 


Modify Service 


Siebel 


The "Modify Service" event will be used to send 
changes to a customefs service from Siebel to Vitria. 
The "Modify Service" event will be automatically 
triggered in Siebel to send information to Vitria when 
any of the service information is modified. A Siebel 
Workflow sends the modified service information to 
Vitria in XML format through HUP protocol. 


2a 


Find Customer 


Portal 


Portal uses the account number in the opcode 
PCM0PCUS1JIHD to determine the account POID. 


2b 


Find Service 


Portal 


Portal will need to retrieve the service poid, using the 
service information sent from Siebel, in order to attach 
the product to the appropriate service. Portal uses the 
opcode PCM OP SEARCH to determine the poid of 
the service. The Fnput parameters for 
PCMJJPJEARCH are the Service Type, the Service 
Login, an inline search template built into the opcode's 
input Hist. 

*Note: In the case that Siebel fails to send service 
information for a defined service-level deal, Portal 
will send back an error to Vitria. 


2c 


Modify Service 


Portal 


Set the service type for the service object in the 
PCM OP CUST MODIFY SERVICE opcode by passing 
it to the s~ervice POID andh INHERITED JNFO array. 
The INHERIT JNFO array contains the effeclve 
date and service location information. 


2d 


Set Password 


Portal 


Set the service password in 
PCMJJPWSTJETJASSWD opcode by passing it 
the account POID, service POID, and password. 


2e 


Acknowledgement 


Porta! 


A response will be sent back from Portal to Vitria 
indicating whether the service has been successfully 
modified or not. 


3a 


Modify Service 
Instance 


Arbor 


This event will be used to modify information related 
to the service instance within Arbor. 


3b 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Vitria 
indicating whether the service has been successfully 
modified or not. 



FIG. 51 
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Se- 
quence 


Svstem Event 


Appli- 
cation 


Description 


1 


Ser::: n ° h J.us 
Notification 


OMS 


The OMS Source Connector will monitor the OMS 
database to see if there is any change in the status 

nf s Qonrirp nt nrnriiirt If f/?PfP ft P PhAftflP if) fhp 

U/ G OC/J VlbU Ul p UUUOU It UlUlU to 0. KjftQSlKjQ III Mb 

status of a service or product, a Service Status 
Notification Event is created with the required parameters. 
The OMS server is accessed to obtain additional 
information. The Service Status Notification Event 
is then sent to the Vitria iOM for handoff to the 
automator. 


0 

L 


Notification 


Wia 
iOM 


Vitria IOM will be responsible for creating and sending 
the Update Product Status Business Event to Siebel 
(for CRM purposes). Wia IOM logic will determine the 
status response to be sent upstream to Siebel. When 
the status is "Active", the Vitria IOM will inform 
Portallkbor to begin the billing process. 


3 


Update 
Product 
Status 


Siebel 


Jhe Update Product Status Event will send product 
update information from Vitria to Siebel. Wia will 
update the CRM application to "Pending" once OMS 
has received a work order. Vitria will also update the 
CRM to "MVe" once the order has been successfully 
provisioned in OMS. Vitria will send this information 
to Siebel in XML format via an HJJP protocol. 



FIG. 5J 
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Se- 
quence 


System Event 


Appli- 
cation 


Description 


1 


Update Account 
Status 


Siebel 


Jhe Update Account Status event sends account status 
information from Siebel to Wia. Jhe Update Account 
Status event is triggered automatically in Siebel when 
a customer's account status is changed. A Siebel 
workflow sends the necessary account information 
to Wia in M format via an HIJP protocol. 


2 




IOM 


Jhe Account Process Model will receive the 
updateAccountStatus event and send it off to billing. 
It will wait for a successful acknowledgement event 
in return from the billing applications to be notified 
with the changes are complete in billing. 




Find Customer 


Portal 


Portal uses the account number in the opcode 
PCM OP CUST FIND to determine the account POID. 


3b 


Update Account 

OIqIUo 


Portal 


Pass the account POID, status, status flag, and 
defaulted Drooram name to 
PCM_OP_CUST_SET_STAWS to set the account 
status to active, suspended, or closed. 


3c 


Acknowledgement 


Portal 


A response will be sent back from Portal to Vitria 
indicating whether the account status has been 
successfully changed or not. 


4a 


Cease Account 


Arbor 


Jhis event will be used to update the status of an 
account to a disconnect requested status by utilizing 
the cease function on the Account API object 


4b 


Reactivate Account 


Arbor 


Jhis event will be used to update the status of an 
account to a current or active status from a closed 
status by utilizing the reactivate function on the 
Account API object. 


4c 


Acknowledgement 


Arbor 


A response will be sent back from Arbor to Wria 
indicating whether the account status has been 
successfully changed or not. 



FIG. 5K 
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Se- 
quence 


System Event 


appli- 
cation 


Description 


1 


Update Product 
Status 


Siebel 


Siebel will send an event to Vitria 10M that will trigger 
the update product event. Once Vitria receives this 
event it will send it on to the provisioning system. 
Vitria IOM will then wait until it receives a provisioning 
request response from the provisioning system (QMS), 
indicating that the event was received. It will then send 
a message onto Siebel letting it know that the request 
has been received. It will then wait for a 
serviceStatusNotification response from the 
provisioning system. Once it has received the 
response it will send the update product Status to 
Siebel to change the status to either complete or 
canceled. 



FIG. 5L 
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Channel Name 


Description 


Business Event 


Publisher 


Subscriber 


AccountChannel 


Events sent to this 
channel will pertain to 
creating, modifying, 
and disconnecting 
accounts 


CreateAccount 
ModifyAccount 
UpdateAccountStatus 
ApplyAccounttevelAdjustment 


Siebel 
Source 
Connector 


Account 
Process 
Model 


Provision 

Order 

Channel 


Events sent to this 
channel will pertain to 
installing and 
disconnecing 
products and 
services 


OrderHeader 

AddService 

ModifyService 

CancelServices 

AddProduct 

CancelProduct 


Siebel 
Source 
Connector 


Order 

Processor 

Model 


JoSiebel 


fill events that need 
to be published to 
the Siebel System 


ServiceStatusMfication 
UpdateProductStatus 


Service 

Processor 

Model 


Siebel 
Target 
Connector 


Provisioning 
Request 


Ml events that need 
tobepubishedto 
the Provisioning 
systems 


ProvisioningReguest 


Service 

Processor 

Model 


OMS 

Target 

Connector 


Provisioning 
Response 


fill events that are 
publshedby 
Provisioning systems 


ProvisioningResponse 
ServiceStatusNoMcation 


OMSSource 
Connector 
OMSJarget 
Connector 


Service 

Processor 

Model 


Acknowledgement 
Channel 


Ml Acknowledgements 
that an event was a 
success or a failure 


Acknowledgement 


ArborJarget 

Connector 

PortalJarget 

Connector 

SiebelJarget 

Connector 


Acknowledgement 

ToFile 

Service 

Processor 

Model 
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Channel Name 


Description 


Business Event 


Publisher 


Subscriber 


Billing 
Channel 


Ml events that need 
to be published to 
the Billing systems 


Createkcount 

Modifykcount 

UpdateAccountStatus 

MpplykcountMdjustment 

MdService 

ModifyService 

CancelService 

mOnOQUCl 

CancelProduct 


Service 

Processor 

Model 


Tokrbor 
Channel 
Mortal 
Channel 


Tokbor 


Ml events that need 
to be published to 
the Mbor System 


Createkcount 

Modifykcount 

UpdatekcountStatus 

ApplykcountbvelAdiustment 

MdService 

ModifyService 

CancelService 

MrlPrndnot 

CancelProduct 


Billing 
Channel 


hrbor 
Target 
Connector 


ToPortal 


Ml events that need 
to be published to 
the Portal System 


Cmtekcount 

Modifykcount 

UpdatekcountStatus 

/\pplykcountl£velJ\djustment 

MdService 

ModifyService 

CancelService 

MdProduct 

CancelProduct 


Billing 
Channel 


Portal 
Target 
Connector 
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